Skip to content

Translate Flux Bool to Prop in Lean and open Classical everywhere#1527

Merged
ranjitjhala merged 3 commits intomainfrom
petros-marko/go-classical
Mar 3, 2026
Merged

Translate Flux Bool to Prop in Lean and open Classical everywhere#1527
ranjitjhala merged 3 commits intomainfrom
petros-marko/go-classical

Conversation

@petros-marko
Copy link
Collaborator

@petros-marko petros-marko commented Mar 2, 2026

  • remove BoolMode from lean formatter; default to translating all occurrences of bool to Prop
  • mark definitions with noncomputable to stop lean from complaining if they indeed happen to be non-computable
  • open Classical in all lean files

TODO

  • test this out a little
  • I'm slightly concerned that the translation might break down when bools appear in non-positive positions, but I don't know of a useful reason we'd do that

Tested by emitting lean files in flux-demo (for sorting related PCs). It seems to work fine. The second point I'm still not sure about, but I think LEM would allow us to do what we need.

@petros-marko petros-marko requested a review from nilehmann March 2, 2026 23:37
fn lean_fmt(&self, f: &mut fmt::Formatter, cx: &LeanCtxt) -> fmt::Result {
let FunDef { name, sort, comment: _, body } = self;
write!(f, "def ")?;
write!(f, "noncomputable def ")?;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this necessary as soon as you open Classical, or do you need it for some specific functions?

@petros-marko
Copy link
Collaborator Author

petros-marko commented Mar 2, 2026 via email

@nilehmann
Copy link
Member

Did you put noncomputable on every def? I want to understand whether we need it just for functions or if it's also necessary for theorems, sort declarations,...

@petros-marko
Copy link
Collaborator Author

petros-marko commented Mar 3, 2026

Did you put noncomputable on every def? I want to understand whether we need it just for functions or if it's also necessary for theorems, sort declarations,...

I put it almost everywhere. I didn't put it on the declarations we make for interpreted rust constants (because I think it's unlikely it'd be required). Let me tinker with it a little and figure out whether other declarations need it, if I had to guess right now I'd say functions definitely require it, theorems, and proofs might sometimes require it, sort declarations probably don't require it.

Update after some more reading, I think only functions should have it.

  • theorems shouldn't (if they were declared with theorem instead of def Lean would even complain about adding it)
  • it also doesn't make sense for proofs
  • maybe a contrived sort declaration could need it, but I think it makes sense not to have it by default.

@petros-marko petros-marko requested a review from nilehmann March 3, 2026 02:05
Copy link
Member

@nilehmann nilehmann left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is closer to what I was expecting. A little sad that we have to mark all functions as noncomputable, but I suppose that's the price we are paying for going classical. We can revisit later...

@ranjitjhala ranjitjhala merged commit d6cec33 into main Mar 3, 2026
9 checks passed
@ranjitjhala ranjitjhala deleted the petros-marko/go-classical branch March 3, 2026 14:32
@ranjitjhala
Copy link
Contributor

Yes, lets try this out and if it hits glitches we can always do the more fine-grained thing...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants